Guten Morgen,
wir beschäftigen uns nun schon seit ein paar Wochen mit dem Thema "externe Cloud-Distributoren" um sie als brauchbares Storage einzusetzen. Unsere Ideen, Methoden und Erfahrungen möchten wir euch hier kurz vorstellen. Anschließend können Interessenten sich gern an Weiterentwicklungen beteiligen, Vorschläge und Ideen einbringen, etc.
Unser Problem ist, wir haben alle irgendwo etwas zu wenig Speicher. Und sollte dem nicht der Fall sein, beschäftigt uns das Thema der Redundanz/Hochverfügbarkeit und Backups. Sicher ist ein Server mit viel Speicher für wenig zu haben - aber sind die Daten dann auch gegen einen Hardware-Defekt geschützt? Nicht immer und schon gar nicht für "wenig zu haben". Also war unsere Idee einen externen Cloud-Speicher wie Dropbox od. Google-Drive als Laufwerk in Linux zu mounten um demnach, wie vom restlichen FS gewohnt, Daten ablegen zu können die keinen lokalen Speicher belegen, vor Ausfall geschützt sind und unter diesen Bedingungen keine Backup-Tasks oder Raid-Controller mehr benötigen.
Die Idee ist schon mal gut...
In der Praxis haben wir uns zuerst mit Linux beschäftigt - da wir auch nicht unbedingt Interessiert sind einen Windows-Server regelmäßig zu warten. Unter Linux gibt es verschiedene - wenige - Möglichkeiten externen Cloud-Speicher von Google anzubinden. Leider haben wir hier mit allen standalone Möglichkeiten keine brauchbare Methode gefunden Daten zuverlässig über mehrere Instanzen und gleichzeitig auf unser neues Laufwerk zu transferieren. Die Verbindungen mit "google-drive-ocamlfuse" und "GDriveFS" sind etwas instabil und ein Datentransfer bricht eigentlich immer zuverlässig ab. "Grive" ist lediglich eine Möglichkeit die API v. Google-Drive anzusprechen, was für uns im ersten Moment nicht weiter interessiert ist... wir das Rad auch nicht neu erfinden möchten.
Probleme ohne Ende...
Die verschiedenen Clients unter Linux waren für uns absolut unbrauchbar. Geschwindigkeiten sind sehr schlecht, Verbindungen brechen ab, das System wird instabil od. hängt sich an Timeout's auf. Wenn man langsam und behutsam damit eine Datei nach der andere kopiert... mag das durchaus funktionieren. Weiterhin haben wir nach dem erfolgreichen "mounten" unter Linux ein FTPD installiert um hier mal zu testen wie es mit FXP-Transfer aussieht. Geschwindigkeiten bis zu 1,5MB/s sind möglich aber auch hier bricht der Transfern gern ab. Wir haben also von der Möglichkeit den Speicher über Linux zu deployen erst mal abgelassen.
Besserung in Sicht...
Zunächst sind wir auf Windows 2008 R2 (SP1) gegangen um mit der Anwendung "WebDrive" des Herstellers South River Technologies das Laufwerk einzubinden. Leider war hier trotz Optimierung der Cache-Settings und der Wahl von Windows keine deutliche Besserung in Sicht. Der Datentransfer lief zuverlässiger aber auch haben wir bei nächstem Versuch über einen FTPD auf das Laufwerk zu Flashen (FXP) bemerkt, dass einige Daten nicht übertragen wurden / der Transfer abgebrochen hat und wir Fehlermeldungen erhielten mit denen nicht wirklich etwas anzufangen war.
Eine brauchbare Lösung...
Zuletzt haben wir noch die Anwendung "NetDrive" des Herstellers Bdrive Inc. - ebenfalls für Windows getestet und hier scheint es als haben wir eine brauchbare / funktionale Lösung gefunden. NetDrive lässt sich als Netzlaufwerk oder physikalisches (Fake)-Laufwerk einbinden. Letzteres hat den Vorteil, dass Anwendungen, die sich nicht auf Netzlaufwerke mappen lassen hier trotzdem zum Einsatz kommen können. Gerade wenn man mit FTPD's arbeitet kommt es vor, dass das HOME-DIR eines Users kein Netzlaufwerk sein kann (ist auch nicht bei jedem FTPD so...). Bei iSCSI haben wir gemerkt, dass Microsoft selbst das Fake-Laufwerk von NetDrive nicht anerkennt (Danke an der Stelle für den zusätzlichen Einsatz von y0l0sw4gg3r) - demnach ist es nicht möglich eine VHD von einem externen Cloud-Speicher als iSCSI zu deployen. Windows kann direkt auf dem externen Speicher (über NetDrive) übrigens keine VHD größer als 1,5TB direkt erstellen. Alles drüber bricht mit der Meldung "Falscher Parameter" ab. Es ist nun zwar möglich ein virtuelles Laufwerk zu erstellen und in Windows einzubinden aber eben nicht per iSCSI zu deployen.
Stabile Lösung gefunden...
Die für uns aktuell stabile Lösung sieht so aus, dass wir NetDrive den Cloud-Speicher mappen lassen, einen FTPD (Filezilla Server) auf dem Windows installiert haben und nun per Linux und "curlftpfs" das Laufwerk auf unserem Linux einbinden. Wir nutzen Linux hier lediglich für Index-Arbeiten und kleinere Daten zum hin-und-her kopieren da leider auch "curlftpfs" nicht gerade optimiert ist um viele Daten in einer annehmbaren Geschwindigkeit zu transferieren.
Transfergeschwindigkeiten
Windows <-> Drive
- schreiben (45MB/s)
- lesen (12,5MB/s)
Client <-> FTPD <-> Windows <-> Drive
- schreiben (31MB/s)
- lesen (9MB/s)
Die Geschwindigkeit ist das nicht das gelbe vom Ei aber eine durchaus brauchbare Lösung wenn man mit automatisierten Prozessen arbeitet, stört das Warten auch nicht weiter.
---
Eigentlich war der Plan Protokolle wie SMB, SSH, iSCSI, FTP über Linux zu deployen aber das mussten wir aus Gründen, wie oben steht, fallen lassen - zumindest bis sich etwas neues ergibt.
Aktuell ungetestet
- Samba-Mount von Windows
- SSH-Mount durch installation eines SSH-Server auf Windows
- curlftpfs Optionen optimieren (aktuell: curlftpfs -o allow_other,big_writes,sync_read,skip_pasv_ip ....)
Zu lösende Probleme
- Linux Mount ohne Gateway (Windows/FTP) zu akzeptabler Stabilität
- Indexierung der im Cloud-Speicher liegenden Daten extrem langsam (Beispiel Linux "find")
Anwendungen zum einbinden von Cloud-Speicher
Microsoft Windows
- NetDrive (Link)
- WebDrive (Link)
Linux
- google-drive-ocamlfuse (Link)
- Grive (Link)
- GDriveFS (Link)
Alternativen (Linux)
- curlftpfs (Link/Wiki)
So. Das sind unsere Erfahrungen bisher damit. Wir denken es ist eine durchaus brauchbare Lösung für einige und wir hoffen es finden sich hier noch Teilnehmer die gern ihre Erfahrungen / Ideen und Vorschläge mit einbringen möchten.
Vielen Dank!
Zitieren
Zitat von Cappa
